Can't authenticate diradmin - how to debug?

In the Server app, under Tools, open Directory Utility

Click the lock to unlock

In Services, double-click LDAPv3

Delete the 127.0.0.1 entry

Then click New to re-bind

Server Name or IP: 127.0.0.1

Accept all defaults.

No need to enter Directory Admnistrator/Password

Quit Directory Utility

See if that fixes it.

If not fixed, follow the steps here to reset the diradmin PW

http://support.apple.com/kb/HT1194

See if this helps...

In Server app, hit command-n to make a new server connection.

Choose Other Mac, and enter: 127.0.0.1 along with your diradmin user/pw

quit server app and delete its prefs

rm ~/Library/Preferences/com.apple.Server.v2.plist

Also delete any keychain entries for "Mac OS X Server Administration"

Do you have server app set to show All Users, Local Network Users or Local Users ?

Try switching it from one of those to another and see if any of them work.

if not, your logs must have a clue... please check.

Im having an identical problem again now.

Its been an ongoing nightmare to get this runnig certainly no worth the time I have put into it.

Im considering either disabling open directly completly and just given every one a local account

or tryign to upgrade to 10.8

any ideas on how painfull the 10.7 to 10.8 upgrade is. ?

My understandign is that they have done away with server Admin in 10.8 and now added open directory into server.app, This intergration should have fixed some of these issues.

Ok .. he we go again .

What appear to have happend is mac ports has added a new user.

The result of that on my system is instant death see pervious posts

Kerbrose server stops .... system fails..

I have the same experience with an upgrade to 10.9 where all my 1500 network users/groups in Server v3.01 are not editable and not addable and password reset is not showing. WGM works as usual and adds users and changes passwords etc which just as well or we would be totally out of action. I had this happen with the last upgrades to Lion and Mountain Lion and I fear I'm going to have to repeat the procedure that fixed it before. Make a clone of your drive as a back up to this if it goes wrong.

First of all export all the services and lists you can possibly do in WGM, select all users apart from your diradmin and all the other groups computer lists and such like. You can also at this stage export the archive of your existing OD master if you want but I found that in my case importing the OD archive back into a newly created OD master just brought back the original problems.

Delete your Open directory and recreate a new master one with a new Directory Admin short name other than diradmin i.e. mladmin(just so you know that everything is new etc). Go to Server app and see if you can add or edit users by adding a test account(I found it was functioning as expected).

Check you can log into WGM using your new directory admin name. If all is well and test user can log/in/out import all your users/computer lists and other data from your WGM exports back into WGM. You will have to reset all the passwords for the network users but this is easy enough to do. All the new imported users should appear in server App accounts and they will be editable and all settings working. Its a bit of a task to do all this but it did restore the functionality of server app. Good luck!

Hope this helps somebody:

I found its "NONE OF THE ABOVE".

In my case its cased by the client not setting the relm correctly. It was using diradmin@127.0.0.1 instead of diradmin@<my dns server name>.

1. Grabbing a Kerberos Ticket via GSAPI interface required diradmin@<my dns server name> and it would fail to get credentials from diradmin@127.0.0.1
2. Ticket is send to the LDAP server which then checks the ticket signature and allows access.

For Simple Authentication <username>/<password> clients seem to be forbidden by internal setting. Which kinda explains the older versions mentioned above switching off those settings.

For OSX Server 3.x.x it seems to be one you have moved passed simple and enable the others restoring the database puts you in the deadlock state of not knowing kerberos will be highly fussy about the realm <dns server name> instead of what the client software defaults to when using simple authentication.

So restoring the proper realm as a client you can go backwards enabling simple authentication again, without restarting restoring databases etc.....

Tjbu, did you ever find the complete solution for this issue? I'm wrestling with the same issue, have tried everything other than the drastic measures suggested by Michael Priestley above and would rather avoid that if possible.

Thanks!

Paul

After doing a 10.10 plus server 4.0 update I had to reset diradmin password.

Mac OS X Server: How to reset the Open Directory administrator password - Apple Support

I was able to fix this by doing what was suggested in the marked helpful reply with one extra step required. I had to enter my directory admin user name and password after removing the existing LDAPv3 entry and rebinding. If you don't enter a directory admin user, you'll bind but still be unable to edit anything even with the directory utility. This was on a 10.8.5 server.

Update: It looks like it's only temporary. I went to the Kerberos ticket viewer application and removed the ticket and now I'm back to not being able to make any changes to the Open Directory server. Going through the process of removing the binding and authenticating again fixes it but I think it will be broken when the ticket expires again.

The error that brought me here was servermgrd[185]: servermgr_accounts: got error 5000 trying to auth to local LDAP node which was coming up after my OD master suddenly disappeared entirely and I performed a restore from an OD archive.